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x Challenges — The Pizza Problem.. 


e 120m al customers 


Challenges - The Pizza Problem... 


+ Vilde spectrum of target customers 
= From end-users to administrators 
* Wart new features but no new learning 
= How do I migrate me users and the cament amme 
© Mast be innovative but fully compatible 
— New features but mo surprises (file formats macros. solutions) 
* Designed te be flexible but lockable 
= Filly custemeable and configurable — but lockable # so mish 
+ Fully loaded but nct bicated 
= My 20% of the features are most important 
— The other 30% should not get in my var 


O 
“Understanding the customer better 


Designing for innovation 


Technology Bets 
and Imperatives 


Designing for innovation 


Technology Bets 
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Concept Sketches -d~ EA Ps 


Designing for innovation 


Technology Bets 


ua and Imperatives 
=> Unertionlabed 
and Inputs —- 


Concept Sketches -d~ Scenario Plans 


How We're Organized 


* Roles: 
- Core: 
* Dev, Test, Prog. Mgmt, User Ed., Marketing 


—Others: 


How We're Organized 


i How Wefre Organized 
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Development Timeline 
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Development Timeline 
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Development Timeline 
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Development Timeline 


Development Timeline 


Development Timeline 


The life of an Office developer 


* Features are assigned 


The life of an Office developer 


* Features are assigned 

* Designs are done 

* Design reviews 

* Features are scheduled 

* Schedule is rolled up and balanced 


The life of an Office developer 


— __ 
The life of an Office developer 


Ape 


The life of an Office developer 


The life of an Office developer 


i About the Code 


* All apps written in C 
Excel, Word 


d About the Code 


How much code is there? 


About the Code 


How much code is there? 


About the Code 


How much code is there? 


ER 
$ About the Code 


« Word in Office 2000 


What we do well 


¡for all disciplines 


Vision 

up from day one 

* Teams organized by feature areas, not apps 
= Where appicatie po 

* Unified test hamess 


- Single schedule db for all apps 


What we do well 


hating ntermational buds. et: 
gong relevant data 


AssertTags 
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Office 10 D.W. Debug AssertT ag Table 


AssertTags (cont.) 


lc, EE 
OfficeWatson 


What we do well 
for developers: 


* Easy to use performance tools 

— Dedicated performance team 

= Some of our own lightweight tools 
* Coding/Scheduling methodologies 


= Bug age limit during milestone coding 


+ Stoned in one database 


Things we're not good at 


* Maximizing coding time 
- Coding to overhead ratio too high 
= Need more robust builds/tests 
much time blocked 
20 many "random" failures today 
* Some tools are too pi 
«The "environment" is too fragile 
— Build break resolution/turn-around 
timeliness 


Things we're not good at 


* How do we reduce bug fixing time? 
- Improve iM code quality 


+ Pre-checkin test deoth/targeing 
* Staging and sub-projects 
= Reduce the number of "spec issue” bugs 


+ One analysis shows this is 4096 of all Dugs 


Things we're not good at 


* Reducing bug fixing time (cont.) 
— Need better way of prioritizing bugs 
+ Gather more data internally & from betas 
- Performance roller coaster 


e Too much "break it now, fix it later 


Things we're not good at 


e Schedule predictability 
- Better data 
— Better model of how things really are 
- Schedule everything 


